Infinity-Get-Apple names a function, with lambda list (CLIENT &OPTIONAL PACKET):
Get the apple to get into, or out of, $Eden.
The “apple” is a seed value for a sort of CHAP/HMAC authentication used only for children signing in to Tootsville. Essentially, the client will ask for an “apple,” as a seed value for hashing with the password. The client sends back this hash, and awaits parental permission.
In the modern usage, the user who wishes to get authenticated connects a stream (ie, WebSocket) connection and sends a packet like this:
{ c: "getApple" }
There are no d data required.
The response from the server will be something like
{ from: "getApple",
status: true,
apple: "an opaque string" }
The default action is to create a new apple value on each call. However, the client can control this with an additional parameter, replace.
The default. A new apple will be returned, superseding any previous value, regardless as to whether any previous value had been given. Previous apple values became irrelevant / no longer can be used.
If an apple value has been issued, do not replace it. An error will be returned on subsequent calls to getApple.
Assert that there must have been a previous apple issued, and replace it. If no previous apple had been issued, an error will be returned.
The apple value will be a valid UTF-8 string without control characters of no more than 4kiB, but no other assertions about it can be assumed by a conforming client.
In the case of an error from getApple, a returned error packet will look like
{ from: "getApple", status: false,
error: "error message text" }
Upon receiving a valid apple string, the client will submit a login packet (see: TOOTSVILLE INFINITY-LOGIN) like:
{ c: "login",
d: { userName: "a-Toot-name",
password: "a-secret-sha1-hex-string",
zone: "$Eden" } }
The pass submitted is a hash created by:
Concatenate the apple value with the downcased version of child-code for the Toot being signed-in.
Take this concatenated string, and take the SHA1 hash of it.
Take the hex value of that SHA1 hash
The login packet will return from: "login", status: true if the password is successful.
Next, parental approval is required. This can be submitted before login, in which case the login will be followed by a slew of other messages as the player signs into the game, or after login. In the latter case, the client will be given the login success message and nothing else. The client is expected to wait and entertain the user until such a time as parental approval comes back.
Parental approval packets are sent by TOOTSVILLE PARENT-GRANT-PERMISSION by way of TOOTSVILLE WS-APPROVE-TOOT; denial, by TOOTSVILLE PARENT-DENY-PERMISSION by way of TOOTSVILLE WS-DENY-TOOT.
During this intermediate time between login and approval, the client's TOOTSVILLE USER-ACCOUNT will be set to NIL but its TOOTSVILLE TOOT will be set to the selected Toot object.
If the parent approves, a packet will be returned like
{ from: "parentApproval",
status: true,
until: UNIX-TIME,
approved: "approved" }
If the parent does not approve (actively denies permission), a packet will be returned like
{ from: "parentApproval",
status: false,
until: UNIX-TIME-NOW,
approved: "denied" }
Following denial, the client is required to cease attempting to log in; it is expected that the child user will be brought to the Wiki page explaining that they have been denied permission.
Following approval, a flood of related login packets will be sent which should trigger the usual login process; these will include positioning the Toot character, observations of the world (so-called ``room variables'' and avatar information, &c.) and other packets. Review the Tootsville.Game.Gatekeeper documentation for the client's handling of these packets.
This mechanism for logins was introduced in 1.1
1.2 switched all communications to JSON, removing XML equivalent legacy commands used by SmartFox Server's protocol.
Defined in file src/websockets.lisp.